Skip to content

scroll fix inside parent#3252

Merged
adumesny merged 1 commit intogridstack:masterfrom
adumesny:master
Mar 31, 2026
Merged

scroll fix inside parent#3252
adumesny merged 1 commit intogridstack:masterfrom
adumesny:master

Conversation

@adumesny
Copy link
Copy Markdown
Member

@adumesny adumesny commented Mar 31, 2026

Description

Checklist

  • Created tests which fail without the change (if possible)
  • All tests passing (yarn test)
  • Extended the README / documentation, if necessary

* fix gridstack#2074
* we now use immediate parent and not just page for scrolling.
* updated two.html to showcase both scroll options
@adumesny adumesny merged commit 417fa0b into gridstack:master Mar 31, 2026
adumesny added a commit to adumesny/gridstack.js that referenced this pull request Apr 1, 2026
* more fixed for gridstack#3252 gridstack#3251
* moved code to dd-draggable, simplifying AI code and making sure mouse up stops animation (release outside of grid)
* fixed Utils.getScrollElement() to look for overflowY auto | scroll (was bogus before)
@adumesny adumesny mentioned this pull request Apr 1, 2026
3 tasks
adumesny added a commit to adumesny/gridstack.js that referenced this pull request Apr 2, 2026
* more fixed for gridstack#3252 gridstack#3251
* getScrollElement() now makes sure there is a visiable active scollbar
* when entiring another grid, make sure to stop prev grid, leaving entire shape out
@danielgindi
Copy link
Copy Markdown

It would be great if we can configure the scrolling behavior - like max speed, or even a delay between dragging the widget to the edge and when the parent scrolling starts.

@adumesny
Copy link
Copy Markdown
Member Author

adumesny commented Apr 3, 2026

@danielgindi let me know if the current behavior (which I can continue tweaking) doesn't work - speed wise. I tend to think adding many options means we didn't get the behavior right and complicates things and having to support it so not wanting to do so. Speed could possibly be tied to mouse scrollwheel speed so they feel similar...

@danielgindi
Copy link
Copy Markdown

@danielgindi let me know if the current behavior (which I can continue tweaking) doesn't work - speed wise. I tend to think adding many options means we didn't get the behavior right and complicates things and having to support it so not wanting to do so. Speed could possibly be tied to mouse scrollwheel speed so they feel similar...

Nope, for me it still scrolls too fast - and I'm a technical person. Users who would want to drag and will have to scroll while dragging - will find it almost impossible to control. I am currently playing with this as a replacement for a dashboard widget grid (hence the work I've done on RTL), but the scrolling speed makes it unusable for us.
This situation happens mostly when the widgets are big. Like 30%-50% height from the viewport's height.

@adumesny
Copy link
Copy Markdown
Member Author

adumesny commented Apr 5, 2026

@danielgindi do you have a video you can post ? is it the widget beign dragged being 30-50% (not others I assume). it suppose to max out and jsut jsut rely on how many px off screen you drag (for that reason) but may have to tweak it more (and maybe even log() it or something instead of linear).

not seeing the issue with 50% large items (we hit the max pretty quickly)

Screen.Recording.2026-04-05.at.7.56.02.AM.mov

@danielgindi
Copy link
Copy Markdown

Are the demos published with 12.5.0 now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Dragging node not activating scrolling inside container

2 participants